Virtual Jukebox: Reviving a Classic

Recent advances in compression technology, combined with lower cost of storage and bandwidth, have made digital distribution of rich content including music not only technically feasible but also popular with a broad audience. However, limited progress has been made in the way this content is enjoyed by end users. In this paper, we focus on the problem of playing music in a shared space – e.g. office, home, car – such that all listeners who are present share a positive music experience. Our scheme enables collaborative selection of content and pooling of content files. Users can express their preferences by contributing songs to be played and through a simple voting scheme. The system builds profiles and automatically selects content for playback, maximizing the match with the group’s taste. As users vote, the system learns more about their collective preferences and can adjust the playlist accordingly, thus providing an incentive mechanism. 1. Background and Motivation For as long as music has existed, it has been a collective experience. Until audio recording made it possible to separate the performance from the listening, music was enjoyed in concerts, large or small; even today, live musical performances continue to attract large audiences to venues ranging from smoky bars to stadiums, from Opera houses to private residences. Although some technologies – most notably the Walkman personal cassette player introduced by Sony in the 1980’s – have indeed made possible and encouraged individual listening, music continues to be enjoyed mainly as a shared experience. 0-7695-1435-9/02 $ Over time, models for selection of recorded content have changed little and slowly. The introduction of audio broadcasting revolutionized the music industry, but since then few developments have significantly affected the way people choose what music to listen to. At one end of the spectrum, an individual may be in full control over what content to play for personal enjoyment or to be shared with others in the same location. At the other extreme, content selection is delegated to disc jockeys, programming managers, and advertisers; individuals are limited to selecting a particular radio station. An icon of popular music tradition in some parts of the world, the jukebox was introduced in the late 1920’s. It offered a simple and affordable model for content selection, a rare and early case of combining interactivity with a group selection process. The history of the jukebox is linked to the diffusion of popular styles of music that were under-represented in the established broadcasting networks. In 1927, The Automatic Music Instrument Company created the world's first electrically amplified multi selection phonograph. Underground tavern owners during Prohibition, who could not afford a live band, could instead attract customers by installing a jukebox, which was provided by an operator at no charge. [1] As new technologies were introduced and social conditions changed, the importance of the jukebox faded but did not disappear completely. Today, jukeboxes containing hundreds of CDs can still be found in the back of some bars or providing a retro touch to the lofts of wealthy individuals. However, many of the same problems that the jukebox model addressed remain. In a shared physical environment, be it an office, car or home, how can the various individual preferences be satisfied? Given that audio can be quite intrusive due to the inability of humans to block sound (unlike images), what model can be used to minimize the negative effect that this intrusion may have on a group of listeners? We revisit the jukebox model of collective 17.00 (c) 2002 IEEE 1 Proceedings of the 35th Hawaii International Conference on System Sciences 2002 selection, eliminating many of the constraints and adding new levels of interactivity made possible by computer technology: inexpensive storage, simple and affordable local area networks, advanced audio compression algorithms and developments in user interface design. 2. The Virtual Jukebox Model The technology we propose, which we have dubbed a virtual jukebox, is a networked music player that downloads music files on demand from distributed storage. It can be implemented on a custom or off-the-shelf embedded computing platform with compressed music decoding in hardware or software, and is connected to speakers or to a stereo system for audio output. The virtual jukebox runs an embedded http server and supports a multi-modal user interface. Users may make selections from their web browsers, through speech commands or using a PDA. Each selection (essentially, a URL) is added to a FIFO queue that controls playback. Since files are stored on the network, the virtual jukebox needs only a limited amount of storage, enough to cache a few titles. Songs can be pre-fetched during playback of the current selection, to assure smooth transitions. In addition to these capabilities, which bring the concept of the jukebox up to date with current technologies, we propose a voting scheme that adds a whole new level of interactivity. As a song is playing, users can vote for or against this title. If enough negative votes are received, the song is skipped and the next song in the queue is played. The system collects votes and builds a profile representing the collective preferences of the community of users. When no selections are pending, the system can automatically make selections on behalf of its users. On a traditional jukebox, this was typically implemented by playing random songs from the list of titles locally available. On the virtual jukebox, we use the history of votes to select not just any song that has been played, but those that are popular within the specific group of users that usually connect to this player. A time limit can be set to make sure that the same song is not played too often and avoid repetition. The system we propose addresses the problem of selecting music in a shared space. For example, in an office environment, audio can help set the mood and may improve productivity. However, musical preferences are quite idiosyncratic, and the wide variety of styles available can lead to significant disagreement within a group as to what particular content is collectively acceptable. By enabling users to contribute their own music collections, we can guarantee that the distributed content database will include a representative sample of the union 0-7695-1435-9/02 $ of all titles that are of interest to the community that develops around it. Voting, on the other hand, can be used to exclude those titles that are not in the intersection of individual preferences. This rule can be relaxed to allow some flexibility, for example playing songs that several members of the community feel strongly in favor of but for which other members have a slight negative bias. Our proposed scheme can help build consensus and a stronger sense of community. The voting scheme can highlight commonalities among users and the method of pooling resources can help expose listeners to content they may not have experienced before. Because the system learns from its users, it encourages a more interactive experience. However, when selection of music takes a low priority for listeners, the system can automatically take over this role on behalf of its community of listeners and taking into consideration their collective preferences. 2.1. Content Selection and Playback The virtual jukebox is not limited to a small collection of titles that can fit in it, like its physical predecessors were. Instead, it can use any compatible content available on the (local) network. In the simplest selection model, a user specifies the URL for a compressed music file, which is downloaded to the jukebox as needed for playback. By adopting this distributed content approach, not only can the selection be unlimited, but also new content can be easily introduced. A user’s personal collection may be incorporated instantly to the repertoire of songs the jukebox can play by just providing the URL in which it can be found. This greatly simplifies pooling of content among members of the listening community. To ease the navigation of possibly large collections of titles, we propose a simple crawling mechanism. If content is organized hierarchically (as would be the case for content stored in the familiar directory structure used by modern computer systems) or in other linked list fashion (e.g. hyperlinks in HTML) then a crawler simple enough to run in a embedded system can follow the links and build a list of music files from a base URL. Moreover, the crawler can read the metadata contained in each file and maintain a small database of titles that can be be browsed and sorted by different criteria, such as author, album or year. Note that this requires very limited persistent storage, as the title themselves are not copied over to the embedded system. The implementation of metadata may vary with the encoding of the content; for example, in the MP3 format, ID3 tags are stored in the last 128 bytes of a file. Thus, a crawler using a protocol that supports downloading byte ranges such as HTTP could read just the appropriate portion of the file to make building this index of titles more efficient. Additionally, every time an individual title is selected, it can be checked against the database and, if it 17.00 (c) 2002 IEEE 2 Proceedings of the 35th Hawaii International Conference on System Sciences 2002 happens to be a new URL, it can be automatically added to the list of crawled titles. The virtual jukebox implements a multi-modal user interface for content selection, including Web browsing, speech and handheld computers. No single UI is absolutely superior to the others, since each one has relative advantages depending on the access mode and the users’ preferences and abilities. The metadata collected by the crawler can be used as the foundation for a speech-based user interface. We combine speech input (recognition) and output (synthesis) to enable sophisticated navigation of data. By restricting the vocabulary to only those words contained in the metadata, the performance of speech recognition can be improved. This may require multiple input/output interactions, for example listing first a list of authors and then, once the user makes a selection, listing albums or titles by the chosen author. Speech input is especially well suited for direct access. For example, a user may say “Play My Way by Frank Sinatra”. The system would then try to find a phonetic match within its vocabulary. The match may not be unique, i.e. there may be several possibilities (e.g. there may be both a live and a studio version, the recognition of the spoken command may be uncertain or the request may be an incomplete specification); in such a case, the system may present a reduced set of options to the user for selection, or play one at random. The current state of the art in speech technology does not guarantee flawless interactions. For example, proper names or creative spellings (Lynyrd Skynyrd comes to mind) may be incorrectly rendered by the speech synthesis system. In addition, speech recognition engines are usually sensitive to ambient noise, and therefore the playback of music during speech-based selection may introduce further errors. While we have considered possible solutions to some of these problems (see Conclusion and Future Work), this is outside the scope of this paper. Note that from an implementation point of view, the speech processing need not be performed on the jukebox itself: network protocols such as VoiceXML [2] allow for interaction via speech with remote systems. Another alternative for navigation of content is through a Web browser. The jukebox is addressable via HTTP (i.e. runs an embedded HTTP server) and serves HTML pages. Using transcoding techniques, any HTML page on the network that contains links to music files or to other pages can be processed by the jukebox (acting as a proxy) such that relative references are made absolute and are included as a parameter to a URL that points to the jukebox. Thus, users can seamlessly access any page, such as the web 1 Pages with JavaScript, applets or some CGI scripts may not be transcoded correctly. 0-7695-1435-9/02 $1 pages served by Apache to represent the local filesystem available via HTTP or FTP. Based on the content type, music files can be identified as such and treated differently: when the user clicks on a link pointing to a music file, this is interpreted as a selection. With more advanced transcoding, the jukebox can support navigation from PDA’s. Naturally, PDA’s would have to be connected to the network, either directly (e.g. wireless card) or through a proxy (e.g. USB to a PC on the network.) Due to the more limited graphics capabilities of most current PDA’s, it may not be possible to access any Web page, as was the case for a full-fledged Web browser. However, the database of crawled content can be presented for selection, possibly with multiple levels of interactivity. A user-initiated selection is not always played instantaneously. The virtual jukebox, just as its more traditional cousins, is in essence a FIFO queue of musical selections. Unlike in a traditional jukebox, however, the content is not locally available. Files could be streamed from their source, i.e. they could be fetched in real time as they are being played. However, due to latency problems on some networks and the uncertain delivery time for packages on TCP/IP, this may lead to interruptions and reduce sound quality. An alternative mechanism, that requires some (nonpersistent) storage is to use a cache. The queue and the cache can work together to pre-fetch files that are coming up for playback. The cache needs only be large enough to contain a few (2-5) songs. With reasonable bandwidth and compression schemes, playback of a song should, on average, take longer than the actual download, thereby guaranteeing that as long as there are enough selections on the queue, transition from one song to the next will be smooth and without interruptions. Of course, if the queue is empty and a new selection is made, there will be a delay before actual playback begins, as this first song is being downloaded. Figure 1 shows these components as well as the user interface modules. The queue manager, the cache and the audio player must be synchronized to guarantee smooth transitions. Each URL on the queue represents a selection. When the current selection is finished playing, the audio player notifies the cache and the queue manager of this event. The recently played file, which was stored on the cache, is marked as unlocked, indicating that it is eligible for deletion. All entries in the queue are bumped up one position, as the top one is removed. The next URL (now the top element on the queue) should already be available in the local cache, and the audio player is pointed at it so that playback can commence. The file is marked as locked, to indicate that it is in use. 7.00 (c) 2002 IEEE 3 Proceedings of the 35th Hawaii International Conference on System Sciences 2002